Application No. 10/680,009 10 Docket No.: S1389.70016US00 

Amendment dated December 18, 2008 
Response to Office Action of August 19, 2008 

REMARKS 

In response to the Office Action mailed August 19, 2008, Applicant respectfully requests 
reconsideration. To further the prosecution of this application, each of the rejections set forth in 
the Office Action has been carefully considered and is addressed below. The claims as presented 
are believed to be in condition for allowance. 

Claims 1-41 were previously pending in this application. No claims are amended, added 
or canceled. As a result, claims 1-41 remain pending for examination, with claims 1,15 and 29 
being independent. No new matter has been added. 

Initially, Applicant's representatives thank Examiner Debnath for the courtesies extended 
in agreeing to conduct a telephone interview after the filing of this response and prior to the 
issuance of any new Office Action. Applicant's representatives look forward to discussing the 
Office Action with the Examiner, and will contact him shortly after filing this response to 
schedule a time to conduct the interview. 

Claim Rejections Under 35 U.S.C. §103 

Independent claims 1, 15 and 29 are rejected under 35 U.S.C. §103(a) as purportedly 
being obvious over PCT Publication No. WO 00/59286 to Seliger et al. ("Seliger") in view of 
U.S. Patent No. 6,934,740 to Lawande et al. ("Lawande"). Applicant respectfully traverses this 
rejection, as each of independent claims 1,15 and 29 patentably distinguishes over any 
combination of the asserted references. 

I. Brief Overview Of Embodiments Of The Invention 

Some embodiments of the invention relate to facilitating the execution of context-sharing 
applications in an environment which includes a context manager that is less than fully-enabled. 
An overview of context sharing and context management systems is provided in the section that 
follows, and a discussion of certain embodiments is provided thereafter. 
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A. Context Sharing And Context Management Systems 

In certain settings, users may provide input relating to a common set of entities, or 
"subjects," to more than one application (p. 1, lines 9-10). For example, in the healthcare field, a 
user may provide input on a particular patient to multiple applications, such as a clinical 
application and a financial application (p. 1, lines 10-14). Before context management systems 
were developed, when the user switched from one application to another, she was forced to 
repeat the entry of data relating to the patient to each application (p. 1, lines 14-15). Context 
management systems enable applications to share data relating to one or more "subjects" (in this 
example, the patient), so that the user need not re-enter data relating to the subject(s) to each 
application. Rather, the user need only switch to the patient within one of the applications, and 
the context management system implements that change for all applications that share the patient 
subject (p. 2, lines 5-8). 

Data describing the subject(s) shared by applications is referred to as a "context" shared 
by the applications (p. 4, lines 8-10). Although the patient subject is an illustrative example, 
applications may share a context defined by any of numerous other subjects as well, or instead 
(p. 1, lines 15-19). For example, applications may share a context defined by the user subject to 
enable "single sign-on" capabilities, so that a user who logs in to a single application is 
automatically given access to other applications that share the user subject (p. 1, lines 15-19). 
Other subjects in the healthcare field include encounter, clinical provider, observation, insurer, 
etc. (p. 1, lines 15-19). Other subjects may be shared in non-healthcare fields (p. 1, lines 15-19). 

A context management system may include a context manager to manage the context for 
multiple context participant applications (p. 2, lines 23-24). Each application may include 
programmed routines enabling communication with the context manager (p. 3, lines 25-29). 
When a user of one of the applications attempts to change the context (e.g., by changing the data 
for a subject, such as by switching from one patient to another in the application), the application 
sends a request to the context manager (p. 4, lines 3-7), which may communicate with other 
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applications in determining whether to change the context (p. 4, line 8-p. 5, line 4). 

B. Managing Context With A Less Than Fully Enabled Context Manager 

Applicant has appreciated that in certain commercial environments, it can be 
advantageous to offer customers the option of purchasing a context management system which 
enables sharing of only a subset of the subjects defined by a particular context management 
specification (e.g., the CCOW standard) (p. 7, lines 6-1 1). For example, some customers may 
wish to purchase a system which allows sharing of only the user subject (e.g., to enable single 
sign-on capability) and not others (p. 7, lines 12-15). Others may wish to purchase a system that 
enables sharing of all subjects except for the user subject (e.g., patient, encounter, etc.), because 
they do not wish to pay more for a single sign-on capability (p. 7, lines 15-18). 

Applicant has also appreciated that if the applications in a computing environment are 
configured to share all subjects defined by a context management specification, but the context 
manager is configured to not enable the sharing of all subjects, the applications could 
malfunction because they are incapable of communicating with the context manager in the 
manner they expect (p. 8, lines 3-9). For example, an application configured to share all subjects 
may request at startup that the context manager provide it with privileges relating to the user 
subject (p. 8, lines 21-26). If the context manager is configured to not enable sharing of the user 
subject (e.g., because the customer did not purchase the single sign-on functionality), it may not 
provide an indication of privileges for the user subject to the application (p. 8, lines 21-26). This 
can create problems, because the application may expect to receive an indication of all relevant 
privileges, including those relating to the user subject (p. 8, lines 26-28). When the application 
does not receive the indication, it may not function properly (e.g., it may not perceive itself as 
having the authority to allow a user to log in) (p. 8, line 28-p. 9, line 2). 

Accordingly, one embodiment of the invention provides techniques for managing context 
in an environment where the context manager is configured to not enable the sharing of all 
subjects defined by a context management specification (p. 7, lines 18-21). In one embodiment, 
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an interface is provided which enables applications to set values for a subject which is not shared 
(in the example given in the paragraph above, the user subject), but rather maintains information 
relating to the unshared subject separately for each application, so that the information is not 
shared by the applications (p. 10, lines 14-17). As such, the interface allows applications to 
communicate with the context manager in the manner they expect and thus function properly, but 
prevents the sharing of an unshared subject (p. 1 1, lines 4-6). 

One illustrative embodiment is described in Applicant's specification with reference to 
FIG. 2, which depicts an environment wherein context manager 305 facilitates a sharing of 
context between applications 301 and 303 (p. 9, lines 1 1-14). In this example, context manager 
305 is configured to enable the sharing of the user subject, but not the patient subject (p. 9, lines 
16-18). Context manager 305 provides an interface which allows applications 301 and 303 to set 
and get values for the patient subject, but maintains the values separately for each application, so 
that the patient subject is not shared between the applications (p. 10, lines 14-17). Specifically, 
context manager 305 maintains a first set of patient information 3 1 3a for application 301 and a 
second set of patient information 3 13b for application 303 (p. 10, lines 19-22). When application 
301 seeks to set the patient subject (as shown at 315), only portion 3 13a is updated, and when 
application 303 seeks to set the patient subject (as shown at 317), only portion 3 13b is updated 
(p. 10, lines 22-24). In this manner, information relating to the patient subject is maintained 
separately for each of applications 301 and 303, allowing each of the applications to set values 
for the subject as expected, and continue to operate normally (p. 1 1, lines 4-6). 

The foregoing summary is provided to assist the Examiner in appreciating various aspects 
of the invention. However, this summary may not apply to each of the independent claims, and 
the language of each independent claim may differ in material respects from the summary above. 
Thus, Applicant respectfully requests that careful consideration be given to the language of each 
independent claim, and that each be addressed on its own merits, without relying on the 
summary above. In this respect, Applicants do not rely on this summary to distinguish any of the 
claims over the prior art, but rely only upon the language of the claims and on the arguments 
provided in the sections that follow. 
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II. Independent Claims 1,15 and 29 

Independent claims 1, 15 and 29 all include limitations directed to a plurality of 
applications each configured to share at least first and second subjects in a context, and 
maintaining values for the second subject separately for the plurality of applications so that the 
second subject is not shared among the plurality of applications. 

In Applicant's previous response (filed June 4, 2008), it was pointed out that Lawande, 
which is relied upon to purportedly satisfy the claim limitations directed to maintaining values 
for a second subject separately for a plurality of applications so that the second subject is not 
shared among the applications, discloses nothing at all relating to context sharing, and instead is 
directed to allowing applications to share data. The Office Action includes a "Response to 
Arguments" section, but fails to address the substance of this point. Instead, the Office Action 
simply repeats the contention that Lawande satisfies these limitations and cites the same 
passages of Lawande cited in the previous Office Action and discussed in Applicant's previous 
response (i.e., col. 1, lines 48-60 and col. 7, lines 10-42). This is a point the undersigned looks 
forward to discussing with the Examiner during the interview. 

Below, Applicant discusses the cited passages of Lawande in detail, as well as other 
portions of Lawande which illustrate that Lawande is exclusively directed to techniques for 
allowing applications to share data, and is not directed to context sharing between applications, 
let alone maintaining values for a subject separately for a plurality of applications so that the 
subject is not shared among the applications. 

A. Disclosure of Lawande 

In a first cited passage (i.e., col. 1, lines 48-60), Lawande discloses that each individual 
application typically accesses data formatted and structured for it, so that unless one application 
is specifically designed to share data with another, sharing data between the applications is 
difficult (col. 1, lines 48-52). Lawande also discloses that the application's task of assembling 
and formatting data for output to the user can be complex (col. 1, lines 53-54). Each application 
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typically employs drivers provided by the operating system to display information to the user, 
but the user interface portion of each application often is substantially custom to that application 
and can represent a significant amount of its code (col. 1, lines 57-60). 

Lawande states that the requirement that each application provide its own interface and 
display capability can be a significant limitation when multiple applications are installed on a 
client device having limited processing and/or storage resources (col. 6, lines 44-47). As such, 
Lawande discloses a software architecture which is said to efficiently use the available resources 
in a client device (col. 6, lines 49-50). 

A second cited passage of Lawande (i.e., col. 7, lines 10-42) includes parts of two 
paragraphs, the first of which paraphrases the language of claim 1 of Lawande (directed to the 
software architecture) and the second of which discloses a method for sharing data between 
applications in a client device (col. 7, lines 10-42). Specifically, the cited passage starts (i.e., at 
col. 7, line 10) in the middle of the first paragraph. The entirety of the first paragraph 
paraphrases all of claim 1 of Lawande (i.e., at col. 6, line 56 - col. 7, line 14). The first 
paragraph discloses that the architecture includes a data store for storing a predefined data 
structure including a first data object and a predefined first template, wherein a first field of the 
first template is tagged as corresponding to the first data object (col. 6, lines 56-62). A first 
application outputs information to a user in a format defined by the first template (col. 6, lines 
62-64). The architecture also includes a server process, executing within a client device, which 
receives a template population request from an application (col. 7, lines 5-6). The server process 
uses the value from the template population request to retrieve a template from the data store 
(col. 7, lines 6-9). Using a tag from a field of the template to retrieve a value from a data object, 
the server process returns the corresponding template populated with the value from the data 
object to the application (col. 7, lines 3-14). Lawande discloses that the architecture may also 
include a second template stored in the data store which has a first field tagged as corresponding 
to the first data object, and a second application process configured to output information to a 
user in a format defined by the second template (col. 7, lines 14-22). When requested by a user, 
the second application process sends a template population request message to the server 
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process, and renders the first template, when populated with data, for display to the user (col. 7, 
lines 22-28). Thus, each application has an associated template, and issues requests to a server 
process to retrieve information from a first (i.e., common) data object (col. 7, lines 10-42). 
When the server process retrieves data from the first data object, it populates the application's 
template with the data and returns it to the application (col. 7, lines 10-42). The application uses 
the template to render the data for the user (col. 7, lines 1 0-42). Thus, this first paragraph relates 
to first and second applications each retrieving data from a first data object and rendering the 
data to a user in a format defined by respective first and second templates. 

The second paragraph discloses a method for sharing data between applications in a 
client device (col. 7, lines 29-30). A first data structure, structured according to a first data type 
definition, stores a first data object from a first application (col. 7, lines 31-35). The first data 
object may be retrieved by a second application by accessing the first data structure using the 
first data type definition, and the second application may output data in the first data object to a 
user of the second application (col. 7, lines 37-42). Thus, this paragraph also relates to first and 
second applications retrieving data in a first data object and displaying it to users. 

B. Lawande Fails To Satisfy The Claim Limitations Directed To Maintaining Values 
For A Second Subject Separately For A Plurality Of Applications So That The 
Second Subject Is Not Shared Among The Applications 

It should be appreciated from the foregoing that the cited passages of Lawande relate to 
techniques whereby data may be shared between applications in a client device using 
predetermined data type definitions (col. 7, lines 10-42). As noted above, Lawande describes 
difficulties associated with applications sharing data, and discloses techniques for resolving those 
difficulties. Lawande simply says nothing, in the cited passages or elsewhere, relating to a 
plurality of applications each configured to share at least first and second subjects in a context, 
let alone to maintaining values for the second subject separately for the plurality of applications 
so that the second subject is not shared among the plurality of applications. 
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C. Modifying Seliger According To The Teachings Of Lawande Would Not Have Led 
One Skilled In The Art To The Claimed Embodiments 

Applicant also pointed out in the previous response that modifying Seliger according to 
the teachings of Lawande would not have resulted in what is recited by any of the independent 
claims. The Office Action fails to address the substance of this point, as is believed to be 
required under MPEP §707.07(f). The substance of this argument is another topic which the 
undersigned looks forward to discussing during the telephone interview. 

Seliger discloses techniques for administering a context management system wherein a 
plurality of applications share a context defined by one or more subjects (Abstract). Lawande 
discloses techniques for enabling applications to share data (col. 7, lines 10-42), and says nothing 
at all relating to the sharing of a context. Thus, if one skilled in the art had applied the teachings 
of Lawande to the system of Seliger at the time of the invention, the result would have been a 
system in which applications share context as taught by Seliger, and share data as taught by 
Lawande. Lawande simply discloses or suggests nothing which would affect the manner in 
which a context is managed in the system of Seliger. 

Given that, the system that would have resulted from the combined teachings of Seliger 
and Lawande would be a system in which a plurality of applications share one or more subjects 
in a context, in the manner taught by Seliger. As the Office Action concedes, Seliger fails to 
disclose or suggest maintaining values for a subject separately for the plurality of applications so 
that the subject is not shared among the plurality of applications, as required by each of claims 1, 
15 and 29. 

D. Conclusion 

In view of the foregoing, each of independent claims 1,15 and 29 patentably 
distinguishes over any combination of the asserted references, such that the rejection of claims 1, 
15 and 29, and of the claims that depend respectively therefrom, under 35 U.S.C. §103(a) as 
purportedly being obvious over Seliger in view of Lawande should be withdrawn. 



1547451.1 



Application No. 10/680,009 
Amendment dated December 18, 2008 
Response to Office Action of August 19, 2008 



18 



Docket No.: SI 389.700 16US00 



CONCLUSION 



A Notice of Allowance is respectfully requested. The Examiner is requested to call the 
undersigned at the telephone number listed below if this communication does not place the case in 
condition for allowance. 

If this response is not considered timely filed and if a request for an extension of time is 
otherwise absent, Applicant hereby requests any necessary extension of time. If there is a fee 
occasioned by this response, including an extension fee, the Director is hereby authorized to charge 
any deficiency or credit any overpayment in the fees filed, asserted to be filed or which should have 
been filed herewith to our Deposit Account No. 23/2825, under Docket No. S1389.70016US00. 

Dated: December 18, 2008 Respectfully submitted, 
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